The eDepot system is designed to manage a collection of HGV (Heavy Goods Vehicle) depots for a haulage company. Associated with each depot is a collection of vehicles and drivers and a depot manager is responsible for organising a work schedule between them.

There are two types of vehicle, trucks and tankers which share some common attributes such as vehicle make, model, weight & reg no. Some attributes are however unique to one of the two types of vehicle such as trucks having a max cargo capacity vs. tankers having a max liquid capacity and type (i.e. chemicals, oils, foodstuffs).

All users of the system have a username and password which they use when logging on to gain access to their work schedule and in the case of depot managers, organise a work schedule between vehicles and drivers which are assigned to that specific depot.

A depot manager may assign themselves a work schedule and are thusly drivers themselves. When a depot manager assigns a work schedule, the eDepot system records which vehicles and drivers are required along with the client’s name and the job start and end date and time. The drivers in question are also informed that an update to their work schedule has been made.

A work schedule initially exists in a pending state with the job start date and time being no less than 48 hours in advance and with a maximum duration of 72 hours. Once the job start date has been passed the work schedule switches to an active state and once the job end date has been passed the work schedule is archived.

From time to time it may be necessary to re-assign a vehicle to another depot. This operation can only be made if the vehicle in question has no currently active or pending work schedule.

The Requirements Document above is only an overview of the system. It does not incorporate every aspect of the system’s functionality. You must use common sense / assumptions along     with the OOAD process to define parts of the system that are poorly described.

You should produce . .
1.    UML UseCase Diagram.
o    Try to use the << uses >> arrow to relate functionality.
2.    List of Nouns from the Requirements Document.
3.    Revised list of Nouns that specify Candidate Classes.
o    Justify why you exclude any Noun.
o    Identify any Noun that might become an Attribute.
4.    UML Class Diagram.
o    Make appropriate use of associations, compositions & aggregations and ensure that you specify multiplicity.
5.    Identify Class Attributes.
o    Specify the data type.
6.    UML State Diagram.
o    Model the high level state transition for a work schedule.
7.    UML Activity Diagram.
o    Model the process of re-assigning a vehicle to another depot at a specific date and time, including checks for a currently active or pending work schedule.
8.    Identify Class Operations.
o    Specify the return data type.
9.    UML Communication Diagram.        NOTE : SAME SCENARIO AS 10
o    Model the process of a depot manager logging on,   browsing through vehicles and drivers and then      organising a work schedule between them.
10.    UML Sequence Diagram.        NOTE : SAME SCENARIO AS 9
o    Model the process of a depot manager logging on,   browsing through vehicles and drivers and then      organising a work schedule between them.

What you should hand in:

A word processed report not exceeding 20 pages.

Marking Scheme/Assessment Criteria:

Assessment    Assessment Criteria    % weighting for part
1    UML UseCase Diagram.    10
2    Nouns&CandidateClasses.    10
3    UML Class Diagram (with Attributes&Operations).    30
4    UML State&Activity Diagrams.    20
5    UML Communication&Sequence Diagrams.    20
6    Quality Assumptions.    10

Guidelines:

•    Correctly reference resources that you use.
•    You must specify any assumptions you make as you make them and include them and any general comments, along with your diagrams.
•    Periodically and during lecture time, workshop sessions will run to help guide you during your OOAD of the eDepot system.

The eDepot system is designed to manage a collection of HGV (Heavy Goods Vehicle) depots for a haulage company. Associated with each depot is a collection of vehicles and drivers and a depot manager is responsible for organising a work schedule between them.

There are two types of vehicle, trucks and tankers which share some common attributes such as vehicle make, model, weight & reg no. Some attributes are however unique to one of the two types of vehicle such as trucks having a max cargo capacity vs. tankers having a max liquid capacity and type (i.e. chemicals, oils, foodstuffs).

All users of the system have a username and password which they use when logging on to gain access to their work schedule and in the case of depot managers, organise a work schedule between vehicles and drivers which are assigned to that specific depot.

A depot manager may assign themselves a work schedule and are thusly drivers themselves. When a depot manager assigns a work schedule, the eDepot system records which vehicles and drivers are required along with the client’s name and the job start and end date and time. The drivers in question are also informed that an update to their work schedule has been made.

A work schedule initially exists in a pending state with the job start date and time being no less than 48 hours in advance and with a maximum duration of 72 hours. Once the job start date has been passed the work schedule switches to an active state and once the job end date has been passed the work schedule is archived.

From time to time it may be necessary to re-assign a vehicle to another depot. This operation can only be made if the vehicle in question has no currently active or pending work schedule.

The Requirements Document above is only an overview of the system. It does not incorporate every aspect of the system’s functionality. You must use common sense / assumptions along     with the OOAD process to define parts of the system that are poorly described.

You should produce . .
1.    UML UseCase Diagram.
o    Try to use the << uses >> arrow to relate functionality.
2.    List of Nouns from the Requirements Document.
3.    Revised list of Nouns that specify Candidate Classes.
o    Justify why you exclude any Noun.
o    Identify any Noun that might become an Attribute.
4.    UML Class Diagram.
o    Make appropriate use of associations, compositions & aggregations and ensure that you specify multiplicity.
5.    Identify Class Attributes.
o    Specify the data type.
6.    UML State Diagram.
o    Model the high level state transition for a work schedule.
7.    UML Activity Diagram.
o    Model the process of re-assigning a vehicle to another depot at a specific date and time, including checks for a currently active or pending work schedule.
8.    Identify Class Operations.
o    Specify the return data type.
9.    UML Communication Diagram.        NOTE : SAME SCENARIO AS 10
o    Model the process of a depot manager logging on,   browsing through vehicles and drivers and then      organising a work schedule between them.
10.    UML Sequence Diagram.        NOTE : SAME SCENARIO AS 9
o    Model the process of a depot manager logging on,   browsing through vehicles and drivers and then      organising a work schedule between them.

What you should hand in:

A word processed report not exceeding 20 pages.

Marking Scheme/Assessment Criteria:

Assessment    Assessment Criteria    % weighting for part
1    UML UseCase Diagram.    10
2    Nouns&CandidateClasses.    10
3    UML Class Diagram (with Attributes&Operations).    30
4    UML State&Activity Diagrams.    20
5    UML Communication&Sequence Diagrams.    20
6    Quality Assumptions.    10

Guidelines:

•    Correctly reference resources that you use.
•    You must specify any assumptions you make as you make them and include them and any general comments, along with your diagrams.
•    Periodically and during lecture time, workshop sessions will run to help guide you during your OOAD of the eDepot system.